Blkif request notifications use generic ring req_event holdoff

mechanism rather than custom mechanism.

Signed-off-by: Keir Fraser <keir@xensource.com>

diff --git a/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c b/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c
index bbe6d29acd8152b84954dc22d94eb4e2bb300077..0e2c8105cc82ca18d4a26693e814952be4c4745b 100644 (file)
--- a/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c
+++ b/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c
@@ -498,10 +498,14 @@ static void make_response(blkif_t *blkif, unsigned long id,
          * notifications if requests are already in flight (lower overheads
          * and promotes batching).
          */
-       if (!__on_blkdev_list(blkif) &&
-           RING_HAS_UNCONSUMED_REQUESTS(blk_ring)) {
-               add_to_blkdev_list_tail(blkif);
-               maybe_trigger_blkio_schedule();
+       mb();
+       if (!__on_blkdev_list(blkif)) {
+               int more_to_do;
+               RING_FINAL_CHECK_FOR_REQUESTS(blk_ring, more_to_do);
+               if (more_to_do) {
+                       add_to_blkdev_list_tail(blkif);
+                       maybe_trigger_blkio_schedule();
+               }
        }
 
        if (notify)

diff --git a/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c b/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c
index 0200c779fb8ad2bf8fe05a01083ca828c981dbdc..e7afc76b8e87c486cea8bfad4bf3d634088c28cf 100644 (file)
--- a/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c
+++ b/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c
@@ -395,16 +395,11 @@ static inline void ADD_ID_TO_FREELIST(
 
 static inline void flush_requests(struct blkfront_info *info)
 {
-       RING_IDX old_prod = info->ring.sring->req_prod;
+       int notify;
 
-       RING_PUSH_REQUESTS(&info->ring);
+       RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&info->ring, notify);
 
-       /*
-         * Send new requests /then/ check if any old requests are still in
-         * flight. If so then there is no need to send a notification.
-         */
-       mb();
-       if (info->ring.sring->rsp_prod == old_prod)
+       if (notify)
                notify_remote_via_irq(info->irq);
 }
 

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 924c9d357c95dc3e4bc7dcdc4abe7153a9373383..44780ced7eca23e7ac5392108cfa2d19d9cf0636 100644 (file)
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -12,11 +12,10 @@
 #include "ring.h"
 
 /*
- * Front->back notifications: When enqueuing a new request, there is no
- * need to send a notification if there are old requests still in flight
- * (that is, old_req_prod != sring->rsp_prod). The backend guarantees to check
- * for new requests after queuing the response for the last in-flight request.
- * (NB. The generic req_event mechanism is not used for blk requests.)
+ * Front->back notifications: When enqueuing a new request, sending a
+ * notification can be made conditional on req_event (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
  * 
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic